The present invention relates generally to the transmission of data in a synchronous optical network, and more particularly, to an overhead structure for a data frame in a synchronous optical network.
A standard known as Synchronous Optical Network (SONET) defines a hierarchy of rates and formats for use in optical communications systems, as well as other systems. The CCITT has adopted a similar standard and named it the Synchronous Digital Hierarchy (SDH). The SONET/SDH standard is expected to provide a worldwide telecommunications infrastructure for transmitting information. The terms SONET and SDH will henceforth be used interchangeably. Although, there are small differences between the two formats, the differences are immaterial for the present invention.
As shown in FIG. 1, there are three layers in the SONET architecture. These layers include a section, a line, and a path. A section concerns communications between two adjacent network elements, referred to as a section terminating equipment (STE) 110-1 through 110-6. Regenerators 140-1 and 140-2 and add-drop multiplexers (ADM) 150-1 and 150-2 are examples of STE 110-3, 110-4, 110-2, and 110-5, respectively.
A line concerns communications between line terminating equipment (LTE) 120-1 through 120-4, such as add-drop multiplexers 150. As shown in FIG. 1, a line includes one or more sections. LTEs 120-1 through 120-4 perform line performance monitoring and automatic protection switching. Regenerators generally are not LTEs, although add-drop multiplexers typically are both an STE and an LTE.
An end-to-end connection is called a path and the equipment on either end that sends or receives a signal is called a path-terminating equipment (PTE). As shown in the FIG. 1, a path includes one or more lines which in turn include one or more sections.
SONET uses a basic transmission rate of STS-1, which provides a data rate of 51.84 Mbps. Higher rate SONET signals are integer multiples of this base rate. For example, an STS-3 has a data rate of 155.52 Mbps, or 3×51.84 Mbps.
The frame format of the STS-1 is shown in FIG. 2. The frame 210 is divided into two protions: transport overhead 220 and a synchronous payload envelope (SPE) 230. The SPE 230 is an 87 column by 9 row matrix, for a total of 783 bytes, and is divided into two parts: the STS path overhead 232 and the payload 234. The transport overhead 220 is divided into section overhead 222 and line overhead 224.
FIG. 3, provides a diagram of the transport overhead for the current SONET frame structure. In the current frame structure, the first three rows of the transport overhead contain the section overhead and the final six rows contain the line overhead.
The following table provides a brief description of the section overhead 222 bytes shown in FIG. 3.
ByteDescriptionA1 and A2Framing Bytes - These bytes indicate the beginning of anSTS-1 frameJ0/Z0Section Trace (J0)/Section Growth(Z0) - In an STS-Nframe, this byte is either the section trace byte, if the STS-1frame is the first STS-1 frame in the STS-N frame, or isthe section growth byte, if the STS-1 frame is the secondthrough Nth STS-1 frame in the STS-N frame. This bytewas formerly defined as the STS-1 ID (C1) byte.B1Section bit interleaved parity code (BIP-8) byte - This is aparity code (even parity) for checking for transmissionerrors over a section. In an STS-N frame, this byte isdefined for only the first STS-1 frameE1Section orderwire byte - This byte is used as a localorderwire channel for voice communications betweenregenerators, hubs, and remoter terminal locationsF1Section user channel byte - This byte is set aside for theuser. It terminates at all STEs within a line.D1, D2, D3Section data communications channel (DCC) bytes -These bytes form a 192 kbps message channel providinga message-based channel for operations, administration,maintenance, and provisioning (OAM&P) between STEs.This channel is used from a central location for alarms,control, monitoring, administration and othercommunications needs. It is available for internallygenerated, externally generated, or manufacturer-specificmessages.
The following table provides a brief description of the line overhead 224 bytes shown in FIG. 3.
ByteDescriptionH1, H2STS payload pointer - These pointer bytes are used inframe alignment and frequency adjustment.H3Pointer action byte - This byte is used for SPE frequencyjustification. It is used in all STS-1 frames within an STS-Nframe to carry an extra SPE byte in the event of a negativepointer adjustment. When it is not used to carrythe SPE byte this byte is undefined.B2Line bit interleaved parity code byte - This byte is used todetermine if a transmission error has occurred over the line.K1, K2Automatic protection switching (APS channel) bytes - Thesebytes are used for protection signalling between LTEs forbi-directional APS and for detecting alarm indication signals(AIS-L) and remote defect indication (RDI) signals.D4-D12Line data communications channel bytes (LDCC) - These 9bytes are used to provide a 576 kbps message channel froma central location for OAM&P information, such as alarms,control, maintenance, remote provisioning, monitoring,administration, and other communications needs, betweenLTEs. This channel is available for internally generated,externally generated and manufacturer-specific messages.S1Synchronization status byte - This byte is located in the firstSTS-1 frame in an STS-N frame. Bits 5-8 of this byteconvey the synchronization status of the network.Z1Growth byte - This byte is allocated in the 2nd throughNth STS-1 frame in an STS-N frame where 3 ≦ N ≦ 48,and is allocated for future growth.M0STS-1 REI-L byte - This byte is only defined for an STS-1frame in an OC-1 or STS-1 electrical signal. Bits 5-8of this byte are allocated for a line remote error indicationfunction (REI-L), formerly referred to as Line FEBE.This function conveys the error count detected by an LTE,using the line BIP-8 code, back to its peer LTE.M1STS-N REI-L byte - This byte is located in the third STS-1frame in an STS-N frame, and is used for REI-L purposes.Z2Growth byte - This byte is located in the first and secondSTS-1 frame of an STS-3 frame and the first, second, andfourth through Nth STS-1 frame of an STS-N frame, where12 ≦ N ≦ 48. These bytes are allocated for future growth.E2Orderwire byte - This byte provides a 64 kbps channelbetween LTEs for an express orderwire. It is a voicechannel for use by technicians.
SONET standards have specified a number of management applications whose protocol data units (PDU) are characterized by their large size. These applications include the common management information protocol (CMIP) based Open Systems Interconnection (OSI) management (X.711 or ISO 9596), the file transfer access management (FTAM) based software download and remote back-up applications (ISO 85714), X.500 based directory services, and T1.245 compliant registration management.
Presently, these applications are assigned to the 192 kbps Section Data Communications Channel (SDCC) channel. Because of the large application message size, the total traffic from these applications will exceed the capacity of the SDCC for all but the very simplest SONET networks.
In addition to problems with capacity, there are problems with the current transport overhead structure due to lack of prioritization. Presently, there is no priority mechanism for determining which information can be discarded when the SDCC channel is overloaded. Therefore, in the event the capacity of the SDCC channel is exceeded, information is discarded without any intelligent discrimination. This can result in the loss of vital messages and lead to network failures.
In addition, a number of protocol entities within the OSI seven layer communications stack serving the SDCC conduct peer-to-peer communications over the SDCC, consuming bandwidth that would otherwise be available to management applications. During steady state conditions this protocol traffic is low, however, during abnormal conditions, this traffic can rise to a level that may result in application or protocol traffic being discarded, and thus could lead to network failures.
In addition, the current structure of the transport overhead requires unnecessarily complex SONET interfaces. The current separation of the SONET DCC into SDCC and Line Data Communications Channel (LDCC) requires each SONET interface (that is, both STE and LTE) to terminate an inbound and an outbound SDCC and an inbound and outbound LDCC, for a total of four point to point links per interface. Each of these four links must be brought to a time slot interchange (TSI) for purposes of forwarding or connection to the data link layer of the OSI stack. As such, the TSIs for use with the current overhead structure are unnecessarily complex. FIG. 4 provides an illustration of a TSI 410 of the prior art and shows that TSI 410 receives and transmits information on both the SDCC and LDCC. As such, TSI 410 must drop both the SDCC and LDCC for every interface.
Furthermore, at present the LDCC is under-utilized. This is because, despite its bandwidth being triple that of the SDCC, standards have not assigned any management applications to the LDCC.